EC2のプライベートサブネット移行手順をまとめてみた
2024.11.04こんにちは！AWS事業本部の吉田です。
以前、EC2をプライベートサブネットに移行した際のEC2周りのアクセスについて整理した記事を執筆しました。
EC2をプライベートサブネットに移行した際のアクセス整理（インバウンド・アウトバウンド）
今回の記事では、EC2のプライベートサブネットへの移行手順を具体的にまとめてみようと思います。
移行前
プライベートサブネット移行前は以下の図の構成と仮定します。
（以前の記事の構成から簡略化しています）
- EC2をパブリックサブネットに配置（EC2にパブリックIPを付与）
- HTTPSアクセスの受け口はALB
- 作業者からEC2へ直接SSH接続している
- RDS用のプライベートサブネットは存在している
移行後
プライベートサブネット移行後は、以下の図の構成になります。
事前準備
概要
EC2をプライベートサブネットに移行するにあたって、いくつか事前準備が必要です。
- EC2用のプライベートサブネットを作成
- パブリックサブネットにNATゲートウェイを作成
- EC2用プライベートサブネット用ルートテーブルを作成
- EC2用IAMロールを作成
順に説明します。
EC2用のプライベートサブネットを作成
所謂Web3層アーキテクチャ構成に変更します。
プライベートサブネットを以下の２つに分離することでよりセキュアにする構成です。
- EC2用プライベートサブネット：インターネットからの直接の通信を不可・インターネットへ向かう通信はNATゲートウェイ経由で可能なサブネット
- RDS用プライベートサブネット：インターネットからの通信・インターネットへ向かう通信も不可なサブネット
- 既存のプライベートサブネットをRDS用のプライベートサブネットとして利用
サブネットCIDR設計に基づいてEC2用プライベートサブネット作成します。
もしサブネットCIDR設計が特にない場合、これを機にサブネットCIDR設計を考えてみてください。
サブネットCIDR設計の１例を挙げます。
- 単純な連番
- 10.0.0.0/24、10.0.1.0/24、10.0.2.0/24、10.0.3.0/24
- 用途に応じて分割
- 例1:第３オクテットの２桁目を変える
- パブリックサブネット(第３オクテットの２桁目が0)
- 10.0.0.0/24、10.0.1.0/24
- プライベートサブネット(第３オクテットの２桁目が1)
- 10.0.10.0/24、10.0.11.0/24
- パブリックサブネット(第３オクテットの２桁目が0)
- 例2:CIDRで分割(参考記事:AWSサブネットの切り方を考えてみた)
- パブリックサブネット(10.0.0.0/17)
- 10.0.0.0/24、10.0.1.0/24
- プライベートサブネット(10.0.128.0/17)
- 10.0.128.0/24、10.0.129.0/24
- パブリックサブネット(10.0.0.0/17)
- 例1:第３オクテットの２桁目を変える
今回は以下のサブネットCIDR設計でEC2用プライベートサブネットを作成していきます。
| VPC | CIDR |
|---|---|
| VPC | 10.0.0.0/16 |
| サブネット | CIDR |
|---|---|
| パブリックサブネット(AZ-A) | 10.0.0.0/24 |
| パブリックサブネット(AZ-C) | 10.0.1.0/24 |
| RDS用プライベートサブネット(AZ-A) | 10.0.10.0/24 |
| RDS用プライベートサブネット(AZ-C) | 10.0.11.0/24 |
| EC2用プライベートサブネット(AZ-A) | 10.0.20.0/24 |
| EC2用プライベートサブネット(AZ-C) | 10.0.21.0/24 |
- VPCのサブネットのページに移動し、「サブネットを作成」をクリックします。
- 対象のVPCを選択します。
- サブネットの各設定を設定します。
サブネット名ですが、例えば既存のプライベートサブネット名が「blog-private-subnet-A」なら、「blog-private-ec2-subnet-A」のようにRDS用プライベートサブネットとは別物のプライベートサブネットであることをわかりやすくします。
もしくは、既存のプライベートサブネットを「blog-secure-subnet-A」(private→secure)という風に更新します。
各設定を設定しましたら「サブネットを作成」をクリックします。 - サブネットが作成されたことを確認します。
パブリックサブネットにNATゲートウェイを作成
プライベートサブネットのEC2がインターネットに出る際に利用します。
- VPCのNATゲートウェイのページに移動し、「NATゲートウェイを作成」をクリックします。
- NATゲートウェイの各設定を設定します。
- サブネット：パブリックサブネットを指定してください。
- 接続タイプ：パブリック
- Elastic IP 割り当て：新規にEIPを作成する場合は、「Elastic IPを割り当て」をクリックします。利用していない既存のEIPがあれば、それを選択してください。
各設定を設定しましたら、「NATゲートウェイを作成」をクリックします。
- NATゲートウェイが作成されたことを確認します。
ここで、NATゲートウェイの冗長化について説明します。
例えば、AZ-AのパブリックサブネットのみNATゲートウェイを配置し、AZ-A・AZ-CのプライベートサブネットにあるEC2は共にAZ-AのNATゲートウェイを通じてインターネットに出るとします。
NATゲートウェイがシングルAZ構成の場合、AZ-Aで大規模障害が起きNATゲートウェイがダウンした際、プライベートサブネットにあるEC2がインターネットに出ることが出来なくなります。つまり、NATゲートウェイが単一障害点となります。
そのため、NATゲートウェイはマルチAZ構成にすることが望ましいです。
NATゲートウェイのコスト増加を踏まえて、マルチAZ構成にするか検討してください。
NATゲートウェイを冗長化する場合は、手順の1~3を繰り返してください。
NATゲートウェイの配置サブネットを１つ目のNATゲートウェイとは違うAZのパブリックサブネットを指定します。
今回はシングルAZ構成とします。
EC2用プライベートサブネット用ルートテーブルを作成
EC2用プライベートサブネット用ルートテーブルを作成します。
作成したルートテーブルでインターネットに出るルート、つまりNATゲートウェイをターゲットにしたルートを設定します。
- VPCのルートテーブルのページに移動し、「ルートテーブルを作成」をクリックします。
- ルートテーブルの各設定を設定します。
各設定を設定しましたら、「ルートテーブルを作成」をクリックします。
- 「ルート」タブが選択されていることを確認した後、「ルートを編集」をクリックします。
- 「ルートを追加」をクリックした後、インターネットに出るためのルートを編集します。
- 送信先:0.0.0.0/0
- ターゲット：「NATゲートウェイ」を選択した後、作成したNATゲートウェイを選択します。
設定できましたら、「変更を保存」をクリックします。
- 「サブネットの関連付け」タブをクリックした後、「サブネットの関連付けを編集」をクリックします。
- 今回作成したAZ-AとAZ-CのEC2用プライベートサブネットを選択した後、「関連付けを保存」をクリックします。
今回はNATゲートウェイがシングルAZ構成のため、EC2用プライベートサブネットを一括りにしたルートテーブルを作成しました。
NATゲートウェイがマルチAZ構成の場合は、AZ-AとAZ-Cそれぞれのサブネット用のルートテーブルを作成し、各AZ用のNATゲートウェイをターゲットにしたルートを設定してください。
EC2用IAMロールを作成
SSM Session Managerを利用するため、AmazonSSMManagedInstanceCoreポリシーがアタッチされたEC2用IAMロールを作成します。
既存のEC2用IAMロールがある場合は、AmazonSSMManagedInstanceCoreポリシーをアタッチしてください。
SSM Session Managerに関しては、前回の記事を参照してください。
④作業者→EC2(SSH)
- IAMのロールのページに移動し、「ロールを作成」をクリックします。
- 信頼されたエンティティタイプは「AWSのサービス」を選択し、ユースケースは「EC2 Role for AWS Systems Manager」を選択します。
そして、「次へ」をクリックします。
- ユースケースに「EC2 Role for AWS Systems Manager」を選択すると自動的にAmazonSSMManagedInstanceCoreポリシーがアタッチされています。
「次へ」をクリックします。
- ロール名を設定しましたら、「ロールを作成」をクリックします。
- IAMロールが作成されたことを確認します。
本作業
概要
作成済みのEC2の配置サブネットを変更することは出来ません。
そのため、以下の順番でEC2をEC2用プライベートサブネットに移行します。
- 移行対象のEC2のAMIを作成
- 移行対象のEC2のEBSが暗号化されていない場合、作成したAMIをコピーすることでEBSを暗号化することが可能
- 作成したAMIからEC2用プライベートサブネット上にEC2を作成
- ALBのターゲットグループのターゲットを作成したEC2に差し替える
順に説明します。
移行対象のEC2のAMIを作成
- EC2のインスタンスのページに移動した後、「アクション」→「イメージとテンプレート」→「イメージを作成」の順にクリックします。
- AMIの名前などの各設定を設定します。
データの整合性を確保したい場合は「インスタンスを再起動」にチェックしてください。
各設定を設定しましたら、「イメージを作成」をクリックします。
- EC2のAMIのページに移動した後、作成したAMIのステータスが「利用可能」に更新されることを確認してください。
- (任意)作成したAMIをコピーしEBSを暗号化します。
対象のAMIを選択した後、「アクション」→「AMIのコピー」の順にクリックします。
- 「AMIコピーのEBSスナップショットを暗号化」にチェックします。
KMSキーはEBS用のAWSマネージドキーを選択します。
（カスタマーマネージドキーを利用する要件がある場合、作成したカスタマーマネージドキーを選択してください。）
各設定をしましたら、「AMIをコピー」をクリックします。
作成したAMIからプライベートサブネット上にEC2を作成
- EC2のAMIのページに移動した後、先ほど作成したAMIを選択し「AMIからインスタンスを起動」をクリックします。
- EC2の各設定を設定します。
まずはEC2の名前です。
インスタンスタイプは移行元のEC2と同じインスタンスタイプに設定します。
移行元のEC2のインスタンスタイプが古いファミリーの場合、現行世代のファミリーに変更することを検討してください。
(例：t2→t3)
キーペアですが、SSM Session Managerを利用してEC2に接続する場合は必須ではありません。
キーペアを設定する必要がある場合は、キーペアを設定してください。
（VSCode Remote SSHを利用してリモート開発をする場合など）
AWS Systems Manager と VS Code Remote SSH を組み合わせて快適なリモート開発環境を作る方法
次にネットワーク設定です。
サブネットは作成したEC2用プライベートサブネットを指定してください。
セキュリティグループは既存のセキュリティグループを利用するか、新規に作成してください。
SSM Session Managerを利用する場合、22ポートのインバウンドルールが不要となります。
今回は既存のセキュリティグループを指定します。
「高度な詳細」をクリックします。
そして、IAMインスタンスプロフィールに作成したIAMロールを設定します。
メタデータのバージョンは「V2のみ（トークンは必須）」を設定します。
特別な理由でV1を利用する理由がない限り、V2を設定することを推奨します。
メタデータについては下記の参考記事を参照してください。
[待望のアプデ]EC2インスタンスメタデータサービスv2がリリースされてSSRF脆弱性等への攻撃に対するセキュリティが強化されました！
インスタンス数を設定した後、「インスタンスを起動」をクリックします。
キーペアの設定を特にしていなかった場合、キーペアの設定について確認するポップが現れます。
今回は「キーペアなしで続行」を選択し、「インスタンスを起動」をクリックします。
インスタンスの起動が正常に開始されたことを確認します。
- インスタンスの状態が「実行中」に更新されたことを確認します。
- SSM Session Manegerを利用して、EC2に接続できることを確認します。
EC2を選択した後、「接続」をクリックします。
「セッションマネージャー」タブをクリックした後、「接続」をクリックします。
ターミナルの画面が表示されましたら、正常に接続できております。
ALBのターゲットグループのターゲットを作成したEC2に差し替える
- EC2のターゲットグループのページに移動します。
対象のターゲットグループを選択した後、「ターゲット」タブをクリックして、「ターゲットを登録」をクリックします。
- 作成したEC2を選択します。
EC2への通信のポート番号を設定した後、「保留中として以下を含める」をクリックします。
ターゲットの一覧に作成したEC2が表示されることを確認します。
- 作成したEC2へのヘルスチェックがHealthyに更新されることを確認します。
- 既存のEC2を選択した後、「登録解除」をクリックします。
- 既存のEC2が登録済みターゲットから削除されたことを確認します。
今回は割愛させていただきましたが、上記の作業はユーザーへの影響が大きいためメンテナンス画面を表示させることを推奨します。
ALB上でメンテナンス画面を表示させる方法は以下の参考記事を参照してください。
[新機能]EC2やS3不要！ALBだけでメンテナンス画面を表示するなど固定レスポンスが返せるようになりました！
さいごに
EC2のプライベートサブネットへの移行手順をまとめてみました。
次回は、CodeDeployとGitHub Actionsを利用してプライベートサブネットのEC2にデプロイする方法をまとめていきたいと思います。
（前回の記事の以下のセクションの話です。）
⑤GitHub→EC2(デプロイ)
どなたかのお役に立てれば幸いです。
